Info-Atari16 Digest Fri, 7 Feb 92 Volume 92 : Issue 72 Today's Topics: .SPS picture viewer? All three rez on SM124!!! A non-representitive benchmark... Anti-flamewar proposal. (2 msgs) Atari ST items for sale Circuit drawing programs? FOR SALE TOADFILE 44 REMOVEABLE HARDDRIVE!! HVDI? Notator printer support PD Fortran compiler? Postscript on Atari's in general Problems when trying to exit MiNT Re: Please Educate (soon to be) new Atari user Slowing down my TT ... seriously TT speed comparison.. WANTED: Protracker d'Esion XLI who sells the Reflex card? Welcome to the Info-Atari16 Digest. The configuration for the automatic cross-posting to/from Usenet is getting closer, but still getting thrashed out. Please send notifications about broken digests or bogus messages to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU. Please send requests for un/subscription and other administrivia to Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list instead of the moderators are likely to be lost or ignored. If you want to unsubscribe, and you're receiving the digest indirectly from someplace (usually a BITNET host) that redistributes it, please contact the redistributor, not us. ---------------------------------------------------------------------- Date: 6 Feb 92 22:10:38 GMT From: agate!darkstar!cats.ucsc.edu!monsoon@ames.arpa (Len A. DeJesus) Subject: .SPS picture viewer? To: Info-Atari16@naucse.cse.nau.edu In article <60323@aurs01.UUCP> you write: >I've come across some Spectrum files that use the extention *.SPS... > >Does anyone know of a viewer that can display these? There should be a file in the atari archive called "SPSLIDEX.PRG" that should be used to view these files. Actually, this program will compress spectrum .SPC or .SPU pics, hence the .SPS (smaller? scrunched?) extension so that .SPS are usually smaller (about the size when you arc .SPC files.) NOTE: you might come across some .SPS files which are actually animation done in Spectrum 512 format with the program Unispec so don't try any use the slide show on them. -- Len A. DeJesus (monsoon@cats.ucsc.edu) (tsunami@ucscb.ucsc.edu) -- Len A. DeJesus (monsoon@cats.ucsc.edu) "Hey Mon" (tsunami@ucscb.ucsc.edu) "Blame it on the Rain" ------------------------------ Date: 6 Feb 92 13:50:50 GMT From: mcsun!sun4nl!fwi.uva.nl!gene!schaper@uunet.uu.net (Lancelot Schaper) Subject: All three rez on SM124!!! To: Info-Atari16@naucse.cse.nau.edu I have a PD program with which it is possible to run MED and LOW rez. on a SM124. The only problem is that the screen is split in half. Because LOW rez. uses 320 x 400. I found this program on ftp terminator.umich.cc.edu -- ***************************************************************************** Lancelot Schaper schaper@fwi.uva.nl Faculteit Wiskunde en Informatica 020 - 683.17.78 Universiteit van Amsterdam Nederland ------------------------------ Date: 6 Feb 92 13:41:41 GMT From: mcsun!uknet!bcc.ac.uk!ucacmsu@uunet.uu.net (Mr Stephen R Usher) Subject: A non-representitive benchmark... To: Info-Atari16@naucse.cse.nau.edu I thought some of you might want to know how fast the TT was as compared with other "workstations" using a real application. This is the result of running Rayshade Version 3.0 (no Utah raster toolkit) on a Sun SPARCstation IPX (16Mb RAM) and on an Atari TT030/8. The Sun took approximatly 300 seconds to perform the raytrace of two mirrored balls in front of two mirrors at 45 degrees with a textured floor. The TT took approx 1700 seconds to render the same image. On the Sun, rayshade was compiled using dynamic libraries, the standard Sun C compiler with the -O switch. On the TT rayshade was compiled with GCC 1.40 and mintlib16. The following switches were used:- -O -fstrength-reduce -finline-functions -fforce-mem -fforce-addr -m68020 -m68881 -D_M68881 The define -D_M68881 was used so that the inline assembly functions to use the maths co-processor in the PML math.h header file were used. The executable was set so that it would run in TT RAM and could also Malloc() from it. The code was run under MiNT 0.92. As you can see, the TT performance was about 1/6th that of the Sun IPX (SPARC 2 chip running at 40MHz(?)). As raytracing is VERY floating-point intensive, this suggests that the TT's floating-point performance is about 0.5 Mflops (The IPX is rated at about 3 Mflops). I don't know what this proves, if anything, but there you are! Steve -- Addresses:- JANET:- ucacmsu@uk.ac.ucl or susher@uk.ac.csm Internet:- ucacmsu@ucl.ac.uk or susher@csm.ac.uk ------------------------------ Date: 6 Feb 92 16:57:06 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!qt.cs.utexas.edu !yale.edu!ira.uka.de!math.fu-berlin.de!fub!heaven7.in-berlin.de!cloud9.in-berli n.de!martini@arizona.edu (Martin P. Ibert) Subject: Anti-flamewar proposal. To: Info-Atari16@naucse.cse.nau.edu ( ) In <1992Jan25.215455.14648@ux1.cso.uiuc.edu>, William Magro writes: ( ) > E) Non standard connectors. ACSI, monitor and drive ports, a male rs232 ( ) > port?!?!?! Come on! If you are going to introduce new connectors, at ( ) > least give them advantages over the standard connectors. You must be joking. Since the indroduction of IBM PCs, DTE-type serial ports have always been male. Look on your modem (if you have one). Most likely, it has a female DCE-type connector. Perfect fit, eh? -- __ | Martin P. Ibert, Westendallee 100 d, D-1000 Berlin 19, Germany ( )__ | martini@cloud9.in-berlin.de, also martini@heaven7.in-berlin.de ( 9 )_ |--------------------------------------------------------------- (_________) | All that we see or seem/is but a dream within a dream. --E.A.P ------------------------------ Date: 7 Feb 92 11:24:38 GMT From: mcsun!corton!laas!ralph@uunet.uu.net (Ralph P. Sobek) Subject: Anti-flamewar proposal. To: Info-Atari16@naucse.cse.nau.edu >>>>> On 25 Jan 92 21:54:55 GMT, wmagro@roma.physics.uiuc.edu (William Magro) said: Bill> If you hate posts that respond to flamers, read on. This one is Bill> different. Thanx Bill! Bill> "Why my Atari 1040STf Sucks," by Bill Magro Bill> I) GEM/Desktop has a lot of problems Bill> A) Mouse events are not registered quickly, so if I click on a button Bill> and quickly move the mouse, the button doesn't see the click. Very Bill> annoying, and it slows me down. I have the *exact* same problem on my sparcstation at work running X11R4 and OpenWindows 3. I can quite easily click and move too fast for the X11 events and the machine does the wrong thing. Sometimes I even get it to freeze up completely and have to reboot (or kill X11). Seems just like when some interaction of GEM programs misbehaves, isn't it. Bill> B) I have to bring a window to the front before I can launch a program Bill> from it. In the mac's finder, if I double click on an icon in an Bill> obscured window, the window comes forward and the program runs. In Bill> GEM the window just comes forward. Arghh! This slows me down. A correction seems appropriate! Holding the right key while double clicking *will* run the program in the other window with the current top window serving as current directory. This has been true since TOS 1.0 but seems to be undocumented. Bill> C) I can't arrange my desktop in any efficient way. Not being able to Bill> put programs on the desktop or to arrange them freely in a window Bill> makes launching programs a nightmare. This slows me Bill> down. TOS 2.05 already solves this one! Bill> II) Hardware bitches Bill> B) Our graphics modes suck. 640x400 mono is great for work. But everyone Bill> else has at least 640x400 256 colors available now. The new TT Bill> resolutions should be in _all_ of the machines by now. Come on Atari! How true! Bill> D) The power supply/keyboard/mouse all suck. ... The mice Bill> don't feel very nice and are prone to quickly Bill> wearing out. (Again Mega/TT seem to deal with this.) Do you prefer Mac or Sun mice more? The Suns have at least optical ones but they are large and clumsy. Whatever happend to the *beautiful* small optical Xerox mice that came with their lisp machines? I've heard that they are even compatible with the, shh, Atari ST. Bill> E) Non standard connectors. ACSI, monitor and drive ports, a male rs232 Bill> port?!?!?! Come on! If you are going to introduce new connectors, at Bill> least give them advantages over the standard connectors. Come on now! Things are becoming more and more standardized but still many ANSI terminals come with either male or female RS232 connectors. Likewise for any machine that's more than 3 years old. Bill> By the way, if you decide to followup on this article, please don't include Bill> the whole thing and respond line-by-line. Can you imagine anything more Bill> agonizing than having to read this again in its entirety? Hope I didn't cite too much to offend the net sensibilities. -- Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!laas!ralph If all else fails, try: sobek@eclair.Berkeley.EDU Phone: (+33-)61-33-62-66 FAX-1: (+33-)61-33-64-55 FAX-2: (+33-)61-55-35-77 =============================================================================== Got a Mega 4 ST. Wish it was a Mega STe? :-| Do I *really* want a TT/Next? ;%# ------------------------------ Date: 6 Feb 92 16:56:10 GMT From: sgi!silvlis!patf@ames.arpa (Pat Fitzgibbons) Subject: Atari ST items for sale To: Info-Atari16@naucse.cse.nau.edu I am cleaning out my shelf of unused items. I have the following items for sale. Spectre GCR w/ Mac ROMS - $300 Word Perfect - $65 -- O O O Patrick Fitzgibbons /\ | These are my opinions. \ / patf@silvlis.com /--\ Sunnyvale ) -- Any agreement with my X /\/ \ CA | company is purely / \ in / \ \ coincidental. ------------------------------ Date: 6 Feb 92 19:36:12 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!convex!constellation!a.cs.ok state.edu!cummins@arizona.edu (CUMMINS JOHN WILLI) Subject: Circuit drawing programs? To: Info-Atari16@naucse.cse.nau.edu In article dinsmm@aix02.ecs.rpi.edu (Michael John Dinsmore) writes: > >I am looking for a program that can draw circuits. It doesn't >have to be specifically designed just for electronic cicuits, >but it should be easy to use and not labor intensive just to make >the diagram. > / |\/ |\ > / |/ || Michael Dinsmore > / /| /| || dinsmm@rpi.edu I've had EASYDRAW highly reccomended to me for this use. A set of circuit elements is available (I hear) for cutting and pasting! EASYDRAY is as the name implies "easy to use" but it's not simplistic. It is a capable program. I do not use it for this purpose as I've been too busy to get it and set it up.... jc ------------------------------ Date: 6 Feb 92 22:09:36 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso. uiuc.edu!uxa.cso.uiuc.edu!mpl44572@arizona.edu (Ender) Subject: FOR SALE TOADFILE 44 REMOVEABLE HARDDRIVE!! To: Info-Atari16@naucse.cse.nau.edu I have a 44 Meg Toadfile for sale. This has an ICD adapter, so you can plug it in and go. Comes with all manuals, and a 44meg disk. This is a syquest removable hard drive. $500 (shipping negotiable) Mark ------------------------------ Date: 5 Feb 92 17:07:54 GMT From: mcsun!unido!urmel!tornado!icemark!teppic@uunet.uu.net (B.E.Heinen) Subject: HVDI? To: Info-Atari16@naucse.cse.nau.edu In <1992Feb4.145633.16665@usenet.ins.cwru.edu>, Jason Baker writes: > >What is HVDI? Is it just a screen accelarator like quick/turbo st? Why does >it have its own font? And, most importantly, is it freeware? NVDI (NewVDI) is a commercial screen accelerator like quick st, but in NVDI the main part of accelerating is GEM (not TOS outputs like in QuickST). This doesn't mean, that it is slow in TOS text... NVDI is *REALLY* fast, especially if you have a blitter chip in your ST; NVDI is the first program that fully uses the capabilities of the blitter chip! It has an internal GDOS, too! I can quite recommend it... Ask your local ST dealer for it, for any closer information. yours Benedikt -- ============================================================================= Benedikt Eric Heinen, Matthiashofstr. 3, W5100 Aachen, Germany Voice: +49-241-408592 icemark!sigrorn@tornado.gun.de "When in doubt, print 'em out." -- Karl's Programming Proverb 0x7 ------------------------------ Date: 7 Feb 92 09:44:30 GMT From: timbuk.cray.com!hemlock.cray.com!marc@uunet.uu.net (Marc Bouron) Subject: Notator printer support To: Info-Atari16@naucse.cse.nau.edu Hi People, I'm posting this for a friend `sans network access', so please email any replies to me. Thanks. My buddy would like to know what the printer support is like for C-labs Notator package. He's looking at Epson-compatible printers and has also been somewhat taken by one of the Canon Baby-Jets. He would particularly like to know of anyone's experience of printing scores in landscape format. Many thanks in advance from Rob (and myself). Cheers, [M][a][r][c] ===== Cray Research (UK) Ltd. ===== INTERNET: marc@hemlock.cray.com "If all the girls in Essex were laid JANET: M.Bouron@uk.co.cray end-to-end, no-one would be in the UUCP: ...!uknet!crayuk!M.Bouron slightest bit surprised..." VOICE: +44 344 485971 x2208 ------------------------------ Date: 5 Feb 92 17:11:18 GMT From: mcsun!unido!urmel!tornado!icemark!teppic@uunet.uu.net (B.E.Heinen) Subject: PD Fortran compiler? To: Info-Atari16@naucse.cse.nau.edu In <1992Feb3.205550.52312@cc.usu.edu>, Hoyt J. Heaton writes: >Does anyone out there know of a PD fortran compiler, or have a commercial >version they'd be willing to part with? Here in Germany you can get a program called BCFortran. This is an public domain Fortran, but I don't know if it is quite good, since I don't work in Fortran. If I'll find it somewhere on my PD-disk "collection", I'll send it to atari.archive and tupac-amaru.informatik.rwth-aachen.de . Benedikt -- ============================================================================= Benedikt Eric Heinen, Matthiashofstr. 3, W5100 Aachen, Germany Voice: +49-241-408592 icemark!sigrorn@tornado.gun.de "When in doubt, print 'em out." -- Karl's Programming Proverb 0x7 ------------------------------ Date: 6 Feb 92 18:46:16 GMT From: noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!wupost!zazen!doug.cae.wisc.edu!umn.edu! cs.umn.edu!thelake!steve@arizona.edu (Steve Yelvington) Subject: Postscript on Atari's in general To: Info-Atari16@naucse.cse.nau.edu [In article <697322022.24866@minster.york.ac.uk>, mjl-b@minster.york.ac.uk writes ... ] > What I objected to was the "Calamus is so great I don't see why > you should even consider using anything else" argument. I stated why we > might want to have Postscript output. I think anyone who advances the argument that Calamus is the be-all, end-all of page layout software is ignoring the fact that users' needs come in many shapes and sizes. There is no one perfect tool, and there never will be. > If the Calamus Page Description Language becomes as popular as Postscript, > I'll be happy -- by all accounts it's a better PDL. But although Calamus could > output _both_ Calamus PDL and Postscript, you _still_ have to buy some other > program to do the conversion. Point of clarification: PostScript should not be regarded as a page description language. It's a programming language designed for building graphic images. There's a very big difference. You can't create a page with PageFoo software, write out a .PS file, then edit that page with PageBar on a different platform. You can use the .PS file to build a bitmap on a system (usually a smart laser printer) that has a PostScript interpreter, but that's about it. Calamus doesn't output a programming language. It outputs a bitmap in a format appropriate to the imaging device that is being driven. This allows it to skip several layers of interpretation, resulting in faster throughput. It also allows Calamus to have very precise control over the output image, something that is not possible with PostScript. > I'm not saying that we should stop using the Calamus way of things, just that > the great thing about standards is that they are just that : _standard_. As Henry Spencer says, the great thing about standards is that there are so many of them. > This is not to say that we should never innovate (I hope to god someone > innovates us out of the IBM-PC standard soon). That was accomplished years ago. > When you could support a very > popular standard at little extra cost, Whoa! Who says it would entail ``little'' extra cost? Have you priced Calamus recently? Those modules don't write themselves. Of course it would be possible for the authors of Calamus to create a module that could write PostScript code based on Calamus' document file format or internal data structures. That doesn't mean it would be simple, easy, or cheap, or that the performance would be acceptable to the market at which Calamus is aimed. > but refuse to do it because you > consider it beneath you, that's arrogance. What other serious DTP program > takes this stance? I know of no instance in which Ditek has said it considered PostScript support ``beneath'' it. At any rate, businesses make decisions on the basis of projections of short-term and long-term profitability, not on emotional grounds or ``arrogance.'' If it becomes clear that there's profit in PostScript support, even at the expense of siphoning off scarce resources from other projects, then no doubt you'll see PostScript support. I don't think it's all that clear. There are some serious competitors to Calamus on the way from other developers who are taking a similar approach -- i.e., focusing on high-performance page output by rasterizing the image directly and avoiding PostScript entirely. If I ran the company, I'd be very careful not to get blindsided in my upscale core market while working on a product that would be of interest primarily to people who can't afford a printer. One other comment: The performance issue may be small to you, but to others it is very, very important. The company I work for -- a major daily newspaper -- must typeset thousands of 18-by-22-inch pages per week. Most of those pages are dumped to the typesetter in a very small time window, close to the press deadline. PostScript simply cannot handle the job quickly enough, so we continue to use Autologic APS-5 typesetters whose design is a couple of decades old. We can RIP, record and process (photochemical, resin-coated paper) a broadsheet newspaper page at about 2000dpi resolution in a few minutes. Even the fastest new RISC-based PostScript RIPs can't approach that sort of performance. We're stuck with PostScript on the Macintosh systems used by our infographics specialists. Whenever we must output an infographic on deadline, there's a great round of nail-biting, and often we miss the start of the press run with the color separations. For businesses with our sort of time constraints, the internal-RIP model used by Calamus makes a lot of sense. For the casual user who doesn't own a printer, it's probably not the best solution. Pick another tool. But don't expect it to be perfect. As Voltaire observed, we live not in the most perfect world, but rather the most probable world. --- Steve Yelvington, Marine on St. Croix, Minnesota USA steve@thelake.mn.org umn-cs!thelake!steve ------------------------------ Date: 7 Feb 92 10:01:57 GMT From: mcsun!unido!news.uni-bielefeld.de!uchef153@uunet.uu.net, Menke Subject: Problems when trying to exit MiNT To: Info-Atari16@naucse.cse.nau.edu I have got a problem when I try to leave MiNT. If there is a program running in the background (like lpd), when one trys to leave MiNT the system prints this message: pid 0 (MiNT): assert(`f->links == 0') failed at line 590 of filesys.c. Fatal MiNT error: adjust dedug level and hit a key ... Hitting a key leads to: System halted Press 'x' to exit, or else reboot After pressing x the first messages once again will be printed. Pressing any other key or combination of other keys causes the 2nd message (System ...). Raising the debug level seems to be no help because there is only difference between the regular leaving of mint and the crash: Crash: pid 1 (sh): Fcntl(-1,cmd=0x5407) pid 1 (sh): Fcntl: calling ioctl pid 1 (sh): Pterm(0) pid 0 (MiNT): leaving Pexec with child return code pid 2 (lpd): disposing of closed fifo <---- difference for the crash exit code: 0 pid 0 (MiNT): assert(`f->links == 0') failed at line 590 of filesys.c. Fatal MiNT error: adjust dedug level and hit a key ... Reagular leaving: pid 1 (sh): Fcntl(-1,cmd=0x5407) pid 1 (sh): Fcntl: calling ioctl pid 1 (sh): Pterm(0) pid 0 (MiNT): leaving Pexec with child return code exit code: 0 leaving MiNT Is there a posibility to solve this problem ? Not 'rm u:\proc\*' or manual killing of background jobs. The system I am working on is an ATARI MEGA/STE 4MB. Unfortunatelly I do not know the TOS version I have, because up to know everything works fine. I have not mounted any other filesystem. Carsten Menke carsten@chec02.uni-bielefeld.de or uchef153@unibi.hrz.uni-bielefeld.de ------------------------------ Date: 7 Feb 92 11:29:30 GMT From: noao!asuvax!ukma!wupost!think.com!yale.edu!ira.uka.de!fauern!LRZnews!NewsServ!s eibert@arizona.edu (Ewald Seibert) Subject: Re: Please Educate (soon to be) new Atari user To: Info-Atari16@naucse.cse.nau.edu In article <1992Feb07.070946.45861@yuma.acns.colostate.edu>, sytang@lamar.ColoState.EDU (Shoou-yu tang) writes: |> In article <1992Feb06.232348.6350@cdsmn.mn.org> plate@cdsmn.UUCP (Doug Plate) writes: |> ... |> |> f : means internal floppy drive in the CPU box. |> m : modulator installed (i.e. can hook up to the TV etc.) |> STe and Mega STe are newer ST and Mega with enhancement in it also use SIMMs |> instead of DIPs on older machine. |> TT is 030 machine with different design for more expansion. |> STs has no expansion slot, Mega has one Mega bus for expansion, Mega STe has |> more and TT has VME bus. I think you confused something: Both, MegaSTE and TT have ONE normal length 16-bit VME |> The STs requires hardware hacks to add-in (piggy back, remove etc.) or use |> DMA (hard drive, supercharger) or cartridge port (Spectre). |> STe is about the same except the memory upgrade is easier (change the SIMMs). |> Other probably can provide more information on top this and correct any |> mistake presented. Furtheron, the MegaSTE has a 16MHz 68000-CPU with 16kB cache a LAN port. ============================================================================== seibert@hphalle9.informatik.tu-muenchen.de ist Ewald Seibert, Rheinbergerstr.1 8070 Ingolstadt, 0841-86480 Dont't blame ATARI for things, the GURU told you from the ARABIAN NIGHTS (* ============================================================================== (* = Maerchen aus 1001 Nacht ------------------------------ Date: 6 Feb 92 11:29:18 GMT From: mcsun!uknet!yorkohm!minster!mjl-b@uunet.uu.net Subject: Slowing down my TT ... seriously To: Info-Atari16@naucse.cse.nau.edu In article mforget@ersys.edmonton.ab.ca (Michel Forget) writes: >sms@sys.uea.ac.uk (S.M.Sowerby) writes: > >> This may seem a little silly but I want to make my TT run at ST >> speeds. Not all the time of course, only when running certain > >> Steve Sowerby, Postgraduate layabout, (sms@sys.uea.ac.uk) > >Well, you could try writing an accessory that tells GEM to wait for 10 >ticks, then return. Then do some useless thing like increment some >variables a few thousand times, and tell GEM to wait again. This will >SLOW DOWN the machine like you wouldn't believe. Of course, there are a >few problems. Mainly, it won't work in TOS programs and it will take up >an accessory slot. > [etc.] ><< mforget@ersys.edmonton.ab.ca >> ><< ersys!mforget@nro.cs.athabascau.ca >> ><< Michel Forget >> You could also hook a routine into the VBL queue which wastes time. This will work with all programs, assuming that you can install it before you run the target program (may not be easy for games). Mat | Mathew Lodge | "What do they call you, boy?" "Kate." "Isn't | | mjl-b@minster.york.ac.uk | that a bit of a girl's name?" "... it's | | Summer: lodge%alsys@uknet | short for 'Bob'" -- Blackadder II | ------------------------------ Date: 6 Feb 92 16:36:02 GMT From: mcsun!uknet!bcc.ac.uk!ucacmsu@uunet.uu.net (Mr Stephen R Usher) Subject: TT speed comparison.. To: Info-Atari16@naucse.cse.nau.edu I thought some of you might want to know how fast the TT was as compared with other "workstations" using a real application. This is the result of running Rayshade Version 3.0 (no Utah raster toolkit) on a Sun SPARCstation IPX (16Mb RAM) and on an Atari TT030/8. The Sun took approximatly 300 seconds to perform the raytrace of two mirrored balls in front of two mirrors at 45 degrees with a textured floor. The TT took approx 1700 seconds to render the same image. On the Sun, rayshade was compiled using dynamic libraries, the standard Sun C compiler with the -O switch. On the TT rayshade was compiled with GCC 1.40 and mintlib16. The following switches were used:- -O -fstrength-reduce -finline-functions -fforce-mem -fforce-addr -m68020 -m68881 -D_M68881 The define -D_M68881 was used so that the inline assembly functions to use the maths co-processor in the PML math.h header file were used. The executable was set so that it would run in TT RAM and could also Malloc() from it. The code was run under MiNT 0.92. As you can see, the TT performance was about 1/6th that of the Sun IPX (SPARC 2 chip running at 40MHz(?)). As raytracing is VERY floating-point intensive, this suggests that the TT's floating-point performance is about 0.5 Mflops (The IPX is rated at about 3 Mflops). I don't know what this proves, if anything, but there you are! Steve -- Addresses:- JANET:- ucacmsu@uk.ac.ucl or susher@uk.ac.csm Internet:- ucacmsu@ucl.ac.uk or susher@csm.ac.uk ------------------------------ Date: 6 Feb 92 13:26:19 GMT From: aahs.no!karloey@ucbvax.berkeley.edu (Karl Anders Oygard) Subject: WANTED: Protracker d'Esion XLI To: Info-Atari16@naucse.cse.nau.edu >The following appeared on ST MAGAZINE No 57, JANVIER 92: > >" Le Protracker est un soundtracker tres complet pour un freeware..." This is _not_ correct. I've spent far too much time on ProTracker to release it as freeware. The copy of ProTracker that's floating about was stolen, and should never have gotten out. >Has anybody seen this protracker ? The screen shots look really nice >and can load PACKed files (save disk space). Is it available on any site? There is (should be) a demo copy of ProTracker ST v1.3 on a-a. Take a look at it - v1.3 is a lot better than the illegal copy (v1.2) that's gotten out. ProTracker itself is going to be released commercially under Daatasoft pretty soon. /Email: Karl A Oygard ================================ /Karl Anders Oygard - regd. developer for Atari ======================= ------------------------------ Date: Fri, 7 Feb 1992 08:35 EST From: CSULLOGG@crl.aecl.ca Subject: who sells the Reflex card? To: Info-Atari16@naucse.cse.nau.edu Who sells the Reflex graphics card in North America? Is there a MegaSTE/TT version (i.e. VME)? Thanks in advance! ------------------------------ End of Info-Atari16 Digest ******************************